在Variety主要說的速度問題是指單次任務運算處理的速度，速度的壓力可能來自於使用者對回應速度的要求。所以說，容量問題像是資料流(data pipeline)中的推力，而速度問題像是資料流中的拉力。

在資料處理的過程中，典型的架構就是ETL流程。這個架構是描述將資料從來源端(Data Source)抽取（Extract）後經過轉置（Transform）再載入（Load）至目的端(Data Target)的流程。從速度來看可將資料處理可以分為「批量處理」與「串流處理」，他們有各自的架構且適用不同時間間隔需求的分析場景；在許多系統中更是兩種架構並行，因為即使是同個資料集，經過不同的處理流程也可以萃取出不同的資訊。以下簡單差異比較：

批量處理：Batch Process:
可以使用採用較複雜的分析取得更深入的洞察
延遲可能幾分鐘至數小時
一系列的ETL流程會在同一個處理系統中執行
單次處理資料量相對較大

串流處理：Streaming Process:
可以利用簡單分析提供幾乎即時的反饋
延遲低至秒級甚至毫秒級
ETL流程會在分散獨立在各自串流處理系統中執行
單次處理資料量小

AWS上可以最快速建立的資料處理服務是 — AWS Lambda，它是「無伺服器服務」所以不需要擔心伺服器組態的管理，但使用者仍然可以方便的監控它的狀態。Lambda function會將程式碼靜態加密後儲存在 Amazon S3 中，而程式碼在執行時也會做完整性檢查。每個Function的 /tmp 目錄都有 500 MB 的暫存空間。要注意的是，Lambda最長的執行時間只有15分鐘。

一進到服務首頁可以看到當前帳戶下的所有資源狀態

右方可以直接進入建立function分頁

進入後選定程式執行環境(Runtime)
如果要在特定的網路環境執行可以在進階設定選定VPC(virtual private cloud)，建立後可調整

以建立Python程式碼為例，建立後會進入程式碼頁面，可以在下方code分頁中編寫程式碼，完成後可以在下一個test分頁測試。如果是預先準備好的程式碼，可以從右上角”upload from”從本機上傳壓縮好的ZIP檔，或是將檔案先上傳至S3再給定位置，要注意的是壓縮後的大小不能高過50 MB。

如果是有額外準備的library可以從Add a layer來導入

要監控function的狀態可以到monitor分頁，這裡整合了不只是CloudWatch的報告即時指標，甚至從右上方可以找到更細節的指標狀態。

值得一提的是，Lambda function是無狀態的，這個特性讓每個function可以被事件驅動進而及時擴展以應付使用者需求。因為它的輕量與靈活性，讓它常常出現在需多只需要簡單ETL的架構中以減少開發時間，或是在分析架構中來串接各個分析階段。